Operating systems for computing devices are typically built around a central software component known as a kernel. An operating system's kernel is its core, as the kernel often provides the lowest level of abstraction in the software functionality of the operating system. Thus, the kernel usually interacts with and manages the performance of the hardware resources that an operating system is configured to control. For example, an operating system kernel generally manages the functionality of the central processing unit, system memory, and peripheral devices of the computing system on which the operating system has been deployed.
Most operating system kernels are made up of many subcomponents. For some operating systems, these subcomponents are characterized as kernel modules and kernel tunables. Kernel modules are sections of kernel code dedicated to specific purposes, such as memory management, class drivers, or interface drivers. Tunables (also known as “tunable parameters” or “tunable variables”) are configurable settings in a kernel that can be adjusted according to the specific needs of a particular environment to which the operating system is deployed. For example, kernel tunables may be used to configure aspects of the kernel such as, but not limited to, the number of processes that may be simultaneously active or the amount of memory that may be allocated for certain data structures within the kernel. Some kernel tunables have their values set or changed only when an operating system is booted. Other kernel tunables may be dynamically configured (“tuned”) while the kernel is running on its host device.
Dynamically configured kernel tunables can be set by either an administrator or by the kernel itself in response to changing system usage (absent and administrative decision to override automatic tuning). Current systems of automatic tunable configuration do not distinguish between different processes that cause changes in system resource tunables. For example, a user process may (with or without malicious intent) cause an inline increase of system wide resource limits, thereby leading to increased resource consumption and/or an abnormal allocation of resources that detrimentally affects other processes. As such, this allowance of any process to affect the tuning of the system may compromise system integrity in a bid to be flexible.
Most operating systems are published with a number of kernel tunables. Some of these tunables may be changed without rebooting the operating system. Accordingly, these tunables are dynamically configurable, and may be adjusted while the operating system is running on a particular host device. Typically, default values for the tunables in an operating system are chosen based on the best knowledge of a development engineer and are set at the time of an initial publishing or “cold” install of the operating system. During deployment of a server operating system to a particular host server, these tunables are often further configured by development staff to optimize the kernel for a specific environment. The process to optimize an operating system kernel to a specific workload can cost customers time and resources, and reconfiguration cycles may interrupt normal operations for those who rely on the server.
Often an optimal configuration utilizes skilled administrators, specialized tuning knowledge, and multiple validation cycles to optimally tune an operating system. In certain cases, customers have limited resources and do not wish to invest in a costly customized configuration of this nature. Moreover, the possibility exists that the operating system will become misconfigured and need retuning. One issue associated with retuning an operating system kernel is application downtime.
Current systems of automatic tunable configuration exist in which a user may set upper bounds on resources as tunable values, and when the system detects that the resource limits are being reached, it automatically takes action to increase one or more upper bounds, thereby overriding user settings. This override is done in a bid to improve system availability and reducing user application downtime due to retuning. These approaches also make the system adaptive to the type of load being executed. Additionally, some systems implement the converse—if resource limit tunables were automatically increased, the system may attempt to decrease the resource limit tunables when appropriate.
Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements.